We have successfully notarized our Apple application (within an .mpkg installer).No, you haven't.this works correctly with no general issuesNot according to the rest of your post.There is no way to tell from the information provided what you have done wrong. There are many examples here in the forums of all kinds of different ways to fail at notarization. There are two approaches you can take at this point:1) Run codesign and spct on the downloaded installer. Run console.app and then double-click on it. Do all of this in a VM so you can see a pristine environment.2) From the other end, review how you have constructed the app. Common problems are crazy open source libraries that require all kinds of funky entitlements, crazy cross-platform architectures that do funky things, putting executable code in the resources folder, problems with dynamic libraries and their dynamic library dependencies, codesigning hacks that allow you to get past all of these issues so that you customers can do the code signing debugging on your behalf.

Swift is not compatible with C++, despite, ironically enough, being written in it. You need some kind of bridge that Swift can accept. You can write C wrappers for the C++ and pass everything via void *. Or you can write Objective-C++ wrappers and just hide all of the C++ in categories. There is no easy option.

That's partially correct. You will probably need a private header for objective-C++ so your imported C++ headers aren't visible to Swift. As I said, it's not easy.

Having data in resources usually isn't the problem. The problem is having code in resources. Review console messages when you try to run your app for the first time inside a VM.

Xcode's support for version control systems has always been weak. If you find that certain operations are reliable, then use them. Avoid the ones that are unreliable. But in all cases, double check on the command line.

Review your crash log and Apple documentation.Hopefully you have another version of your crash log that still has the new lines in it.

Use NSWorkspace

I suggest searching for bundle for a resource fork, Finder information, or similar detritus.

It is best to avoid attempting to mix native UI elements with a web view. Don't mess around with the scrollviews at all. If you need to do something in the web view use CSS and Javascript. Since you are in a restricted web view, you don't have to worry about browser compatibility.

I don't know what to tell you that would be more informative than the messages that notarization has already provided. I would suggest keeping things like a JRE in the "Frameworks" folder. I don't know if "Contents" is causing the problem, but "Frameworks" is better suited as a dumping ground of binaries that don't fit elsewhere.

I don't know what else to tell you. Your video doesn't show anything. It is mostly black. Your sample project shows that you did accurately describe what you are attempting. What I am saying is that you should consider a web view to be an opaque object. Don't try to do anything with its scroll views directly. Even if, somehow, you get to to where where every one else has failed, you stand an excellent chance of having it all break again with some minor OS update. How are you going to fix it then?There is no problem having a web view that occupies only a portion of another view. That's fine. Just stay out of the internals. Maybe use a stack view with the header on top and the content below. You might need to calculate how big your web view really is and resize it to match so that only the top-level scroll view is useful. You don't want double-scrolling, unless you do.

None of your examples use a private, Objective-C header. For that reason, they aren't ever going to work in a real-world project.See this forum post. Here is an example of what this would look like in the real world. All of this code, including the comments is generated. It doesn't do much, but it does show how to encapsulate a C++ object in Objective-C, from whence it can be used in Swift. You will have to be very careful with object hierarchies. If I remember correctly, I did come up with a way to handle that using the Swift bridging file. I don't have an example of that anywhere handy. That is the source of the underscore prefix in this example code. I would never use an underscore prefix in real life. It was for some kind of hack.I'm not using the architecture I described in that post. It was just an experiment. I'm just using all Objective-C++. I strongly suggest that you do likewise. If you absolutely must use Swift, then you should write a custom Objective-C++ interface, using the model described above, that calls into your C++ project at a high level and performs the operations that you need.Swift is truly the work of genius. But it is a genius of social engineering, not technical.

Well, I guess I went too far. I guess the forums still do have moderation. Here is a slightly edited version of the moderated post:None of your examples use a private, Objective-C header. For that reason, they aren't ever going to work in a real-world project.See this forum post. Here is an example of what this would look like in the real world (See gist.github.com/etresoft/076679ecef38521b5283554dca62e70f). All of this code, including the comments is generated. It doesn't do much, but it does show how to encapsulate a C++ object in Objective-C, from whence it can be used in Swift. You will have to be very careful with object hierarchies. If I remember correctly, I did come up with a way to handle that using the Swift bridging file. I don't have an example of that anywhere handy. That is the source of the underscore prefix in this example code. I would never use an underscore prefix in real life. It was for some kind of hack.I'm not using the architecture I described in that post. It was just an experiment. I'm just using all Objective-C++. I strongly suggest that you do likewise. If you absolutely must use Swift, then you should write a custom Objective-C++ interface, using the model described above, that calls into your C++ project at a high level and performs the operations that you need.Swift is truly the work of genius. But it is a genius of social engineering, not technical.

I can, and did, elaborate, but then I accidentally clicked your github link and lost it all. It's all a moot point anyway.I reviewed the github project and it is just barely C++. It is just some had-coded equations. My advice would be to just rename "IF97.cpp" to "IF97.Swift" and then fix the code. You'll have 10,000 errors until it stops counting, but just go through it and fix them one by one. It won't take as long as you think. If you are handy with regular expressions and/or BBEdit, you could automate a lot of it.That would be easier than trying to implement what I proposed above.

You get rid of them. You don't need them in Swift.